home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group98a.txt
/
000090_icon-group-sender _Wed Mar 4 12:22:06 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
3KB
Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id MAA23043
for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Wed, 4 Mar 1998 12:22:05 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
id AA06262; Wed, 4 Mar 1998 12:22:05 -0700
Date: Wed, 4 Mar 1998 09:41:45 -0700
From: swampler@noao.edu (Steve Wampler)
Subject: Re: Icon translation
To: icon-group@optima.CS.Arizona.EDU
Message-Id: <swampler-9802041641.AA00091256@orpheus.gemini.edu>
In-Reply-To: <s4fd27c1.030@housmtp.oceaneering.com>
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Content-Length: 2245
Charles Hethcoat wrote:
>
> The only real way to speed up Icon is to build a custom computer
> architecture specifically to execute the Icon-generated abstract code.
Actually, I suspect there are ways to get rather substantial performance
gains from Icon with an 'optimizing' compiler. However, the type of
optimization I'm thinking of is very difficult. If I were independently
wealthy, I'd pursue it, but I'm not. Plus, Icon is already 'fast enough' for
most of my needs.
If you carefully profile Icon programs, you may notice that there's a
'base cost' spread throughout the entire system. This is what makes
it look as though Icon can't be sped up much - a rather high, flat
cost foundation. I believe that a significant fraction of this base
cost is due to the use of descriptors in the implementation. (Don't
misunderstand me, I'm not knocking descriptors - they are a *major*
factor in the flexibility and power of a language like Icon.)
If you look at 'most' Icon programs, though, a human can determine that
much of the transfer of data in the program can be identified and typed.
This is one of the important features of Ken Walker's Icon-to-C optimizer,
removing unneeded type checks. What that optimizer stops short of
doing is removing the unneeded descriptors themselves.
If you know the type, there is very little need left for a descriptor, only
strings [unless something has changed...] use the descriptor for anything
else than a [type,value] pair. Since descriptors are twice the size of
values in Icon, and twice the native machine word size on most (all?)
implementations, programs spend twice as much time pushing
descriptors around as they would raw values. Not to mention all the
redundant type checks in the runtime system (in most circumstances)
and the pulling apart and putting together of the descriptors.
An *amazingly good* optimizer should be able to strip descriptors from
most places (not all) in an Icon program. With appropriate support
from the runtime system, speeds very close to C should be possible from
an Icon compiler.
--
Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)]
The gods that smiled at your birth are now laughing openly. (Fortune Cookie)